系列：《我用 AI 養出一個 AWS 維運同事》｜撰於 2026-09｜Kiro IDE 1.0

昨天留了一個問題沒解

Day 5 講完「踩過的雷會自動蒸餾進錯題本」，但我故意留了一個洞沒補：

錯題本裡的知識會過期。 我三個月前查證的某個限制，今天 AWS 可能改了。誰負責定期把這些老知識抓出來、跟官方重新對帳？

如果又是「我手動來」——你知道的，撐不過三天。所以我把這件事，設計成讓 AI「睡覺」時自己做。

靈感來自人腦：睡眠會鞏固記憶

先講個有意思的科學背景。人為什麼要睡覺？其中一個關鍵功能是鞏固記憶：白天發生的一堆瑣事（短期記憶），會在睡眠時被大腦重新整理、篩選、把有用的轉存成長期記憶，沒用的淡忘掉。

這在 AI 領域有個對應的名字，叫 sleep-time consolidation（睡眠時鞏固）。我整套記憶系統的骨幹就是抄這個：

白天做事（對話）→ 晚上睡覺整理（背景 hook）→ 短期記憶慢慢變成長期知識。

而且我把「睡覺」分成兩種深度——淺睡和深睡，因為它們該做的事輕重差很多。

淺睡：每次對話結束都做的輕整理

淺睡對應一個叫 auto-soul-sync 的 hook，觸發時機是「每次對話結束」（agentStop）。它每天要跑很多次，所以只能做輕活，絕不能燒錢：

1. 滾動：把工作日誌 Hot 層裡超過 7 天的條目，搬到 Warm 層
2. 分流：這次對話有沒有值得記的決策/踩雷？有就寫進日誌
3. 貼標籤：如果是服務專屬的雷，打上 #待沉澱 等歸檔
4. 輕量沉澱：待沉澱的雷攢夠了，順手併進錯題本

注意，淺睡刻意不做那件最花錢的事——上官方文件逐條重查。因為它每次對話都跑，如果每次都去翻官方，token 會燒到你哭。淺睡只做「整理」，不做「查證」。

深睡：手動觸發、做重活的深度整理

深睡對應另一個 hook auto-dream，觸發時機是「我手動按」（userTriggered）。它做的是淺睡不敢碰的重活：

1. 月度壓縮：把 Warm 層超過 30 天的日誌，壓成月度摘要沉進 Archive
2. 知識對帳（重點）：掃描錯題本裡「超過 3 個月沒驗證」的條目，上 AWS 官方文件逐條重查，有出入就以官方為準改掉，並記一行 changelog
3. 建新錯題本：某個服務的雷累積夠多了，自動開一個新的知識檔

這件事很重、很花時間，所以我不讓它自動跑，而是我想到、有空的時候手動觸發，讓它「做個大夢」把整個知識庫翻新一遍。

為什麼要分兩種睡眠？

一句話：頻率和成本要匹配。

如果你把「上官方重查」這種重活塞進每次對話都跑的淺睡，你的 AI 會又慢又貴；如果你把「搬日誌」這種輕活留到手動深睡才做，那 Hot 層早就爆給你看了。該自動的自動、該手動的手動，各安其位。

小工程細節：我還用兩個獨立的旗標檔（純文字記日期）分別記「上次淺睡沉澱」和「上次深睡做夢」的時間，避免它們互相踩到——淺睡不去動深睡的進度，免得害深睡的官方對帳被跳過。這種「兩個計時器分開記」的龜毛，維運排程的人應該很有共鳴。

這對維運的啟發

這套「淺睡/深睡」其實就是維運排程的老道理搬到記憶管理上：

• 高頻的輕任務（健康檢查、log 輪替）→ 自動、常跑、要輕
• 低頻的重任務（全量掃描、對帳、重建索引）→ 排程或手動、間隔久、可以重

你不會讓資料庫每分鐘做一次 full vacuum，也不會一年才輪替一次 log。記憶系統一樣，用對頻率，比用力做更重要。

照著做：我的實際設定

淺睡和深睡是兩個 hook，差別在觸發時機和做多重的事。

淺睡：每次對話結束自動跑（agentStop），只做輕活：

// .kiro/hooks/auto-soul-sync.kiro.hook
{
  "enabled": true,
  "name": "靈魂同步（淺睡）",
  "description": "對話結束時滾動超齡記憶、判斷是否有值得記的新資訊、標記待沉澱知識。",
  "version": "7",
  "when": { "type": "agentStop" },
  "then": {
    "type": "askAgent",
    "prompt": "掃描本次對話做三件事。\n\n(A) 自動滾動：讀 memory.md，找出距今 > 7 天的條目，剪下並**保留全文**貼到 memory-warm.md 對應月份區塊底部。即使條目含『關鍵/踩雷/架構選型』字樣也一律搬走（原文證據留 warm，不佔 hot 的 always 成本）。\n\n(B) 新資訊寫入，先過 GATE：只有『決策結論 / 踩雷教訓與事實修正 / 進度里程碑 / 查證結論』四類才記；純操作步驟、閒聊、還沒定案的討論一律不寫。過 GATE 後：同主題同天先合併不新增、每條 ≤120 字、超過就重壓成「主題+關鍵教訓+結果」、hot 超過 20 條要提醒。\n\n(C) 知識沉澱標記：若該條是某個服務專屬的技術雷或查證結論，在條目末尾加 `#待沉澱:<服務>` tag。**只標記、不要更新知識檔**（知識檔留給深睡慢慢蒸餾）。\n\n沒有可記資訊且無超齡條目 → 不輸出任何訊息。"
  }
}

深睡：我手動觸發（userTriggered），做重活：

// .kiro/hooks/auto-dream.kiro.hook
{
  "enabled": true,
  "name": "Auto-Dream（深睡）",
  "description": "手動觸發的深度整理：知識沉澱、跟官方對帳、warm 壓縮進 archive。",
  "version": "2",
  "when": { "type": "userTriggered" },
  "then": {
    "type": "askAgent",
    "prompt": "執行深度整理，依序做：\n\nA. 掃所有 `#待沉澱:<服務>` tag，依服務分組併入對應的 knowledge-<服務>.md（去重、不重複既有條目），bump 該區塊的『最後驗證』日期、檔尾 Changelog 加一行，並把 memory 條目的 tag 改成 `#已沉澱`。某服務沒有對應檔且累積 ≥ 3 條 → 複製範本開新檔。\n\nB. staleness 對帳：挑出『最後驗證』距今 > 3 個月的知識區塊，用官方文件重新查證，產出「本地 vs 官方」比對表，不符者以官方為準改寫並記 Changelog。\n\nC. warm → archive：把 30 天以上的條目壓成月度摘要搬進 archive。\n\n完成後更新旗標檔記錄執行日期，並回報「更新 X 檔 / 新建 Y 檔 / 清掉 Z 條待沉澱」。"
  }
}

為什麼要拆兩個？因為 agentStop 是每次對話都跑的——你塞在裡面的東西，等於加在每一次互動的成本上。所以淺睡只做「搬位置、標記號」這種零思考的活；要重新查官方文件、要重寫知識檔那種燒錢的重活，一律丟給我按下去才跑的深睡。

這個分法後來變成我設計 hook 的通則：先問「這個 hook 多久跑一次」，再決定能塞多重的活。 高頻的要輕到幾乎沒感覺，重活要嘛低頻、要嘛手動。跟排 cron job 一模一樣的思路。

我還多做一件事：深睡跑完會寫一個旗標檔記錄「上次整理是哪天」（我用 .kiro/.last-dream 和 .kiro/.last-consolidate 兩個，一個給手動深睡、一個給輕量自動沉澱）。這樣淺睡就能自己判斷「距離上次整理超過 N 天了，順手做一點」——不然你設了深睡，也只會忘記按。

帶走的三個重點

1. AI 的知識會過期，要有機制定期跟官方對帳。 別讓錯題本變成過時知識的墳場。
2. 把「整理」分成淺睡和深睡。 高頻輕活自動跑、低頻重活手動做，成本才匹配。
3. 這就是維運排程的老道理。 高頻要輕、低頻可重，用對頻率勝過用力做。

到這裡，記憶與知識這套「大腦」講完了。明天回到維運現場，用一個每天燒掉幾千塊美金的 CloudWatch 費用案，讓你看看這套錯題本怎麼把一次破案變成永久資產。

✍️ 關於作者：康子晉，做 AWS 維運與架構，日常跟一堆帳號、費用、架構圖為伍。這個系列記錄我怎麼把 AI 從「會聊天」調教成「能扛維運的同事」。
🔗 LinkedIn